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FIELD AND BACKGROUND OF THE INVENTION 

5 The present invention relates to a method and device for searching an ordered 

database containing key entries, and, more particularly, to a method and device for 
searching a monotonically-ordered database using transformed keys. 

It is known that a large storage capacity is required for data packet classification 
and forwarding, in which large amounts of information must be stored in the 
10 information base. Storage space limitations affect all state-of-the-art ASEs, including 
Content Addressable Memories (CAMs) such as Binary CAMs and Ternary CAMs. 
Storage space limitation is also a key issue in the search engine technologies of HyWire 
Ltd. 

Searching techniques typically require repeated accesses or probes into the 
15 memory storage in order to perform key comparisons. In large storage and retrieval 
systems, such searching, even if augmented by efficient search algorithms such as a 
binary search or higher-order B-tree searches or prefix B-tree searches, often requires 
an excessive amount of time (clock cycles). 

Another well-known and generally faster method for storing and retrieving 
20 information from computer store involves the use of so-called "hashing" techniques. In 
a system using hashing, the key is operated upon by an operator to produce a storage 
address in the storage space. The operator is called a hashing function, and the storage 
space is called a hash table. The storage address is then used to access the desired 
storage location directly with fewer storage accesses or probes than sequential or binary 



searches. Hashing techniques are described in the classic text by D. Knuth entitled 
The Art of Computer Programming , Volume 3, in "Sorting and Searching", pp. 506- 
549, Addison-Wesley, Reading, Mass. (1973), and more recently, in the contemporary 
classic text of R. Sedgewick entitled Algorithms in C++ , pp. 231-243, Addison-Wesley, 
5 Reading, Mass. (1992). 

Hashing functions are designed to translate the universe of keys into addresses 
uniformly distributed throughout the hash table. Typical hashing operations include 
truncation, folding, transposition and modulo arithmetic. A disadvantage of hashing 
techniques is that more than one key can translate into the same storage address, 

10 causing "collisions" in storage or retrieval operations. Some form of collision- 
resolution strategy must therefore be provided. For example, the simple strategy of 
searching forward from the initial storage address to the first empty storage location 
will resolve the collision. This technique is called linear probing. If the hash table is 
considered to be circular so that addresses beyond the end of the table map back to the 

15 beginning of the table, then the linear probing is done with "open addressing," i.e., with 
the entire hash table as overflow spare in the event that a collision occurs. 

An alternative to linear probing is a technique commonly referred to as "double 
hashing" or "multiple hashing". When more than one key translates into the same 
storage address using the first hash function, the collision can be resolved by selecting a 

20 different hash function and "rehashing" those keys (that had returned identical results 
using the first hash function) in order to differentiate between them. Of course, there is 
a finite probability that more than one key will translate into the same storage address 
using the second hash function, in which case the new collision can be resolved by 
selecting a (different) third hash function and "rehashing" those keys once again in 

25 order to differentiate between them. This process can be repeated until all collisions 
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have been resolved. According to Sedgewick, double hashing uses fewer probes, on the 

average, than linear probing. Sedgewick cites several examples of improved hashing 

methods, but cautions against 

'premature use of advanced methods except by experts with 
5 serious searching applications, because separate chaining 

and double hashing are simple, efficient, and quite 
acceptable for most applications/ 

One area in which multiple hashing is less effective or even problematic is 

network applications. Although the average speed is an important parameter in such 

10 applications, a more important and often overriding requirement is a highly predictable, 
deterministic operation. For example, voice and video recordings can be transmitted as 
data via the Internet using a digital data channeL The Internet network utilizes routers 
to direct the data from the sending address to the destination address. Routers using 
multiple hashing routines to locate the destination address and deliver these data 

15 packets will have a characteristically high variance in the time required to locate the 
address. In most cases, typically about 70%-80% of the time, the multiple hashing 
technique will locate the destination address in the first memory access. However, in 
about 20%-30% of the time, a second memory access is required. Often, a third, fourth 
or fifth memory access is required in order to locate the address. Moreover, in the case 

20 of voice transmission, a high variance of this kind results in a broken up, non-uniform 
sound message. These disturbances are often referred to as "jitter". 

United States Patent No. 6,434,662 to Greene, et al., discloses a system and 
method for searching an associative memory using input key values and first and 
second hashing functions. After a first hash function, the hash-based associative system 

25 allows for the selection of a second hash function that has been pre-computed at table 
build time to be perfect with respect to a small set of colliding key values, provides a 
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deterministic search time independent of the number of table entries or width of the 
search key, and allows for pipelining to achieve highest search throughput. 

Although the deterministic search time is of advantage, the pre-computing to 
identify the second hash function is laborious. Moreover, the pre-computing must be 
5 redone, inter alia, each time that an entry is added to or removed from the database. 

Moreover, while hashing methods are suitable for exact search applications, 
hashing methods are inherently inappropriate for range search applications. 

Also known in the art are Prefix B-trees, in which each node is searched in the 
same manner as a B-tree, but each key Kj in a Prefix B-tree is not a full key but is a 

10 prefix to a full key. The keys Kj of each node in any subtree of a Prefix B-tree all have 
a common prefix, which is stored in the root node of the subtree, and each key Ki of a 
node is the common prefix of all nodes in the subtree depending from the 
corresponding branch of the node. In a binary variant of the Prefix B-Tree, referred to 
as a Prefix Binary Tree, each node contains only one branch key and two branches, so 

15 that there are only two ("binary") branches from any node. The Prefix Binary Tree is 
searched in the same manner as a Binary Tree, that is, branching left or right depending 
on whether the search key is less than or greater than the node key. There are also Bit 
Tree variants of the Prefix Binary Tree wherein distinction bits rather than prefixes are 
stored in the nodes. In particular, the values stored are the numbers of the bits in the 

20 keys that are different between two prefixes, thus indicating the key bits to be tested to 
determine whether to take the right or left branches. 

It may thus be summarized that in the various types of Prefix Trees, a 
compression-like scheme is used to reduce the size of the entries stored in the tree. The 
key-compression approach has the benefit that the entire key value can be constructed 

25 without accessing data records or de-referencing pointers. 
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However, as noted by Bohannon, et ah, in "Main-Memory Index Structures with 

Fixed-Size Partial Keys" (March 28, 2001): 

typical compression schemes such as employed in prefix B-trees 
have the disadvantage that the compressed keys are variable- 
5 sized, leading to undesirable space management overheads in a 

small, main-memory index node. Further, depending on the 
distribution of key values, prefix-compressed keys may still be 
fairly long resulting in low branching factors and deeper trees. 

Bohannon, et al., go on to propose a partial-key approach that uses fixed-size 

parts of keys and information about key differences to minimize the number of cache 

misses and the cost of performing compares during a tree traversal, while keeping a 

simple node structure and incurring minimal space overhead: 

A key is represented in a partial-key tree by a pointer to the data 
record containing the key value for the key, and a partial key. For 
a given key in the index, which we refer to as the index key for 
the purposes of discussion, the partial key consists of (1) the 
offset of the first bit at which the index key differs from its base 
key, and (2) / bits of the index key value following that offset (/ is 
an input parameter). Intuitively, the base key for a given index 
key is the most recent key encountered during the search prior to 
comparing with the index key. 

Bohannon, et aL, articulate that "of the indexing schemes studied, partial-key 
trees minimize cache misses for all key sizes". Bohannon, et al., further articulate that 
"the partial-key approach relies on being able to resolve most comparisons between the 
25 search key and an index key using the partial-key information for the index key. If the 
comparison cannot be resolved, the pointer to the data record is de-referenced to obtain 
the full index key value." Thus, in the partial-key method taught by Bohannon, et al., 
the cache misses during the search operation, however reduced with respect to other 
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indexing schemes, are a finite statistical probability that must be contended with. This 
partial-key method is thus inherently non-deterministic. Moreover, the possibility of 
such a cache miss renders pipelining using hardware solutions impractical, if not 
impossible. 

5 There is therefore a recognized need for, and it would be highly advantageous to 

have, a high throughput, fully deterministic method of searching a database, a method 
that is efficient with regard to memory space, requires a low bandwidth, enables quick 
and facile maintenance of the database, and is inherently suitable for a pipelined 
hardware architecture. 

10 

SUMMARY OF THE INVENTION 

The present invention is a method and device for searching a monotonically- 
ordered database using transformed keys. 

According to the teachings of the present invention there is provided a computer- 
15 implemented method of searching an ordered database using transformed key entries 
including the steps of: (a) providing a system having: (i) a memory for storing a 
plurality of key entries, and (ii) processing logic for transforming the key entries into 
coded entries, and for searching the coded entries; (b) performing a pre-determined 
transformation of each key entry so as to obtain a plurality of coded entries, and (c) 
20 performing a deterministic search in at least one data structure within the memory to 
obtain a match between an input key and a key entry. 

According to another aspect of the present invention there is provided a 
computer-implemented method of searching an ordered database using transformed key 
entries, the method including the steps of: (a) providing a system including: (i) a 
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memory for storing a plurality of key entries; (ii) processing logic for transforming the 
key entries into coded entries, and for searching the coded entries; (b) performing a 
transformation of each key entry of the plurality of key entries so as to obtain a plurality 
of coded entries; (c) arranging the coded entries in a search-tree structure having at least 
5 one node, such that each node includes a plurality of the coded entries, and (d) 
performing a deterministic search within at least one node of the search-tree structure so 
as to obtain a match between an input key and a key entry. 

According to yet another aspect of the present invention there is provided a 
computer-implemented method of searching an ordered database using transformed key 
10 entries, the method including the steps of: (a) providing a system including: (i) a 
memory for storing a plurality of key entries, and (ii) processing logic for transforming 
the key entries into coded entries, and for searching the coded entries; (b) performing a 

A 

pre-determined transformation of each key entry so as to obtain a plurality of coded 
entries; (c) arranging the coded entries in a search-tree structure having at least one 
15 node, such that each node includes a plurality of the coded entries, and (d) performing a 
pipelined search within the search-tree structure so as to obtain a plurality of matches, 
each of the matches representing a match between a particular, respective input key and 
a particular key entry of the key entries. 

According to further features in the described preferred embodiments, the search 
20 is deterministic with respect to specific key data. 

According to still further features in the described preferred embodiments, the 
specific key data includes the input key. 

According to still further features in the described preferred embodiments, the 
specific key data includes the key entries. 
25 According to still further features in the described preferred embodiments, the 
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specific key data includes the coded entries in the data structure. 

According to still further features in the described preferred embodiments, the 
search is a pre-determined search. 

According to still further features in the described preferred embodiments, each 
5 coded entry includes information relating to at least one different key entry. 

According to still further features in the described preferred embodiments, a 
first coded entry includes positional information relating to a first different key entry, 
and a second coded entry includes positional information relating to a second different 
key entry. 

10 According to still further features in the described preferred embodiments, the at 

least one different key entry is a single key entry. 

According to still further features in the described preferred embodiments, the 
information includes information resulting from at least one varying bit. 

According to still further features in the described preferred embodiments, the at 
15 least one varying bit includes a most significant bit. 

According to still further features in the described preferred embodiments, the 
transformation is a deterministic transformation. 

According to still further features in the described preferred embodiments, the 
transformation is a pre-determined transformation. 
20 According to still further features in the described preferred embodiments, the 

performing of the deterministic search includes: (i) processing the coded keys to 
determine a required set of auxiliary data, the set being required to proceed with the 
search, and (ii) using the required set of auxiliary data for an additional processing of 
the coded keys so as to determine a result of the search. 
25 According to still further features in the described preferred embodiments, the 
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auxiliary data includes a portion of a key entry, and the portion is then compared to the 
input key. 

According to still further features in the described preferred embodiments, the 
search is an exact search, wherein the performing of the deterministic search includes: 
5 (i) processing the coded keys to determine a required set of auxiliary data, the set being 
required to proceed with the search, and (ii) comparing the set with the input key to 
determine a result of the search. 

According to still further features in the described preferred embodiments, when 
a certain match exists between the input key and a key entry, the deterministic search is 
10 performed solely by processing of the coded keys. 

According to still further features in the described preferred embodiments, the 
method further includes the step of: storing the plurality of key entries in a particular 
order. 

According to still further features in the described preferred embodiments, the 
15 particular order is a monotonic order. 

According to still further features in the described preferred embodiments, the 
transformation is a unidirectional transformation. 

According to still further features in the described preferred embodiments, the 
each coded entry includes positional information relating to a different respective key 
20 entry. 

According to still further features in the described preferred embodiments, the 
search within each node or list is deterministic with respect to a required amount of 
auxiliary data. 

According to still further features in the described preferred embodiments, the 
25 auxiliary data includes at least a portion of a key entry. 
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According to still further features in the described preferred embodiments, the 
size of the auxiliary data equals less than half of the size of the key entries. 

According to still further features in the described preferred embodiments, the 
auxiliary data is a portion of a single key entry. 

5 

BRIEF DESCRIPTION OF THE DRAWINGS 

The invention is herein described, by way of example only, with reference to the 
accompanying drawings. With specific reference now to the drawings in detail, it is 
stressed that the particulars shown are by way of example and for purposes of 

10 illustrative discussion of the preferred embodiments of the present invention only, and 
are presented in the cause of providing what is believed to be the most useful and 
readily understood description of the principles and conceptual aspects of the invention. 
In this regard, no attempt is made to show structural details of the invention in more 
detail than is necessary for a fundamental understanding of the invention, the 

15 description taken with the drawings making apparent to those skilled in the art how the 
several forms of the invention may be embodied in practice. 
In the drawings: 

Figure 1 shows a schematic example of a B-tree structure for a search procedure 
in a very small database containing 512 words, each having 128 bits; 
20 Figure 2 shows an example of partitioning of the first column (FC) Register into 

three hierarchical blocks, B 2 Register, B 1 RAM and B° RAM, and 

Figure 3 shows a particular case of the example of an FC-Register partitioned 
into three hierarchical blocks, as depicted in Figure 2. 
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DESCRIPTION OF THE PREFERRED EMBODIMENTS 



The present invention is a method and device for searching a monotonically- 
ordered database using transformed keys. 

The principles and operation of the search method and device of the present 
5 invention may be better understood with reference to the drawings and the 
accompanying description. 

Before explaining at least one embodiment of the invention in detail, it is to be 
understood that the invention is not limited in its application to the details of 
construction and the arrangement of the components set forth in the following 
10 description or illustrated in the drawing. The invention is capable of other 
embodiments or of being practiced or carried out in various ways. Also, it is to be 
understood that the phraseology and terminology employed herein is for the purpose of 
description and should not be regarded as limiting. 

In this method, a one-to-one deterministic transformation is applied to the Key 
15 Entries to generate a second database with corresponding "short" or "compacted" 
Transformed (or "Coded") Keys, each consisting of a number of bits that is lower than 
that of the original "long" Key Entries. The Transformed Keys can be used in search 
trees to reduce the size of nodes in each tree level, where each node has one or more 
entries. If the length of the Key Entries is reduced by a specified factor when 
20 transformed into "short" Keys, then the size of each node can be reduced accordingly. 
If the same number of nodes is kept in the tree level, the bandwidth is reduced by the 
same factor for each node, so the time for retrieving a node is reduced. Alternatively, 
the number of entries per node can be increased by the same factor, thereby reducing 
the number of tree levels. In either alternative, or using a combined solution involving 
25 a convenient tradeoff, the search rate increases significantly. Another alternative is to 
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retain the previous consumed bandwidth, enabling the support of a much larger 
database. 

The transformation applied to the Key Entries to generate the corresponding 
short Keys can be unidirectional. The database with the short Keys can be arranged in 
5 monotonic order as the original database, and can be used to perform most of the search 
procedure to identify a "short" Key corresponding to a long Key Entry that may match 
the Searched Key. Then, only a portion of ("a portion" meaning a fraction > 1) a long 
Key Entry (of the original database) that corresponds to the identified short Key is 
compared to the Searched Key to as part of the search process to establish a definite 

10 Match or No-Match. This method yields a faster search procedure and less search 
hardware due to the lower number of bits to be processed. In the case of very large 
databases, the Key Transformation can be applied recursively to short Keys to generate 
an increasingly smaller number of bits to process. 

One way of implementing a deterministic transformation of the Key Entries to 

15 generate short Keys is by coding each long Key Entry according to its relative position 
in the database or in reference to the value of a neighboring Key Entry. The resulting 
Coded Key is then unique and a search procedure yields necessarily a specific Coded 
Key in case of a Match. In particular, a Coded Key may be determined by comparing 
the corresponding long Key Entry with the previous Key Entry in the database and 

20 recording the position index of a changing bit (also termed "varying bit"), e.g., the most 
significant bit (MSB) among the changing bits in the long Key Entry. 

An exemplary search method involving a one-to-one deterministic 
transformation algorithm, denoted as a Search Method using Coded Keys (SMCK) 
algorithm, is described in detail hereinbelow. In this method, the long Key Entries are 

25 coded to generate a list of Coded Keys, each Coded Key having a length equal to the 
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logarithm in base 2 of the length of the corresponding long Key Entry. The list of 
Coded Keys, which requires a small fraction of the storage space required by the 
original list of long Key Entries, is stored along with the original list of long Key 
Entries. However, most of the search procedure is performed within the list of Coded 
5 Keys instead of the long Key Entries, yielding a faster search and most efficient use of 
the data busses. A fast preliminary search operation is performed in the list of Coded 
Keys to find a potentially matching Coded Key. The search method then proceeds with 
a comparison of the Searched Key with the long Key Entry corresponding to the 
potentially matching Coded Key. If the long Key Entry does not exactly match the 

10 Searched Key, then a focused search is performed in a limited set of Coded Keys 
around the Coded Key determined by the preliminary search; this focused search yields 
a Key Index. The Key Index allows the retrieval of the long Key Entry and/or 
Associated Data (AD), as necessary. This search method can be implemented in 
hardware or software for use in any database. 

15 The method of the present invention may serve to code and search data in 

various RAM-Based CAM configurations, some of which have been disclosed in 
previous U.S. Patent Applications to HyWire Ltd. These include RAM-Based Binary 
CAM, dealing with binary integers (integers with single values), disclosed in U.S. 
Patent Application Serial No. 10/229,054, and RAM-Based RCAM, used for range 

20 integers (integers within a range of values) disclosed in U.S. Patent Application, Serial 
No. 10/229,065. 

The coding and search method can be applied to Multi-RAM Binary CAM and 
RCAM configurations, disclosed in U.S. Patent Application Serial No. 10/206,189, 
which teaches multiple RAMs integrated in a single device. The coding and search 
25 method can also be applied to the Associative Search Engine (ASE) disclosed in a co- 
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pending U.S. Patent Application entitled "Multi-Dimensional Associative Search 
Engine Having an External Memory", also assigned to HyWire Ltd. 

All of the above-referenced applications are incorporated by reference for all 
purposes as if fully set forth herein. 

5 

Coding Principle 

It is noted in passing that the exemplary coding principle described hereinbelow 
and the successive search and maintenance procedures are developed under the 
assumption that the long Key Entries and the corresponding Coded Keys are arranged 
10 in monotonically ascending order. However, it will be recognized by one skilled in the 
art that various other conventions regarding the order of the Key Entries and the Coded 
Keys are possible. Similarly, the comparison of bits, described hereinbelow, could be 
performed in alternative ways, and is therefore presented as an exemplary comparison 
method. 

15 A Coded Key is the position index of the most significant bit (MSB) among the 

changing bits in a long Key Entry when compared to the previous Key Entry. If a Key 
Entry consists of N bits, then only log2 N bits (or the closest larger integer) are needed 
to represent any position index of this Key Entry in binary notation. Thus, a Coded 
Key consists of a number of bits equal to the closest integer larger than Iog 2 N. In the 

20 examples presented below, the Coded Keys are represented in decimal notation. 

Table 1 shows an example of applying this method for coding the Key Entry 
101110 stored after 101000. The current Key Entry differs from the previous one in 
two bits located in positions 2 and 1 (in decimal notation); according to the disclosed 
method, the Coded Key corresponds to the MSB among the two, i.e., 2. The Key Entry 

25 bit that corresponds to the Coded Key, denoted as the "Coded Bit", is shadowed. The 
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Coded Key requires in this case (for a Key Entry with 6 bits) a number of bits equal to 
the closest integer larger than Iog2 6, i.e., 3 bits. 

It should be noted that the Coded Key is generated under the assumption that the 
first Key Entry in a list or the Key Entry preceding the first one in a list has a specified 
5 reference value. For simplicity (and by convention), this value is usually "all zeros", in 
this case, 000000. Thus, the Coded Key is the MSB that is equal to 1. The "all zeros" 
value is a special case, and although it does not have a "1" bit, it is assigned a Coded 
Key = 0. 

10 Table 1: Example of a Coded Key Corresponding to the Change in a Long Key 

Entry 





Key Entry 
(5432 10) 




Coded Key 


Previous Key Entry 


101000 




5 


Current Key Entry 


101110 


— > 
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Basic Search Procedure Using Coded Keys 

15 Two basic search procedures using Coded Keys are disclosed: an Exact Search 

and a Range Search. 

In a regular Exact Search, the Searched Key SK is compared with the key 
entries Kj listed in the database in search for an Exact Match (identical values). If there 
is a Key Index i such that SK = K;, then the key entry Ki matches the Searched Key. In 
20 this case, the Key Index i can be used to retrieve the Associated Data (AD) listed under 
the same index. The AD can serve, inter alia, as a pointer to a node in a succeeding 
search level. If SK ^ Kj for all indices i, then there is No Exact Match and no valid AD 
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can be retrieved. 

In a regular Range Search, the Searched Key SK is compared with the key 
entries K\ in search for a Range Match (inclusion within a range). If there is a Key 
Index i such that Kj < SK < Kj+i, then K s matches the defined searched range; the Key 
Index i can be used to retrieve the AD listed under the same index. If the submitted key 
is larger than all the key entries in the database, then the last key entry is defined as the 
matching key. If SK < K\ for all indices i, then there is No Match and no valid AD can 
be retrieved. 

The Exact and Range search procedures are significantly expedited when Coded 
Keys are used, but the corresponding long Key Entries must meet the Exact and Range 
Match conditions as in the regular search procedures. The list of Coded Keys must be 
generated from the corresponding Key Entries prior to their use in the search 
procedures. 

A sequential search of the submitted key in a databse using Coded Keys can be 
completed in two steps in case of an Exact Search and three steps for a Range Search. 
The first step of both search procedures is identical. In the Basic Exact Search 
Procedure, the search procedure consists of: 

• Step 1: Fast preliminary search operation in the list of Coded Keys to find a 
potentially matching Coded Key. 

• Step 2: Comparison of the Searched Key with the long Key Entry corresponding 
to the potentially matching Coded Key. In the case that the keys are equal, the 
matching Key has been successfully identified, allowing, inter alia, for the 
retrieval of the AD. If the keys are not equal, then a matching key does not exist 
in the database. 

An Exact Search procedure of a submitted key that is definitely (i.e., known to be) 
contained in the database does not require access to long Key Entries. In this case, the 
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search is performed only in the list of Coded Keys (first step), because the potentially 
matching Coded Key found in this step is certainly the matching Coded Key, and no 
further check of the long Key Entry is required. 

In the Basic Range Search Procedure, the search procedure consists of: 

5 • Step 1: Fast preliminary search operation in the list of Coded Keys to find a 
potentially matching Coded Key. 

• Step 2: Comparison of the Searched Key with the long Key Entry corresponding 
to the potentially matching Coded Key. In case of an Exact Match, the 
matching Key Index can be used to retrieve the long Key Entry and/or the AD, 

10 as necessary, according to the Exact Match procedure. 

• Step 3: If no Exact Match is found, a focused search is performed in a limited 
set of Coded Keys around the Coded Key determined by the preliminary search 
in step 1, so as to yield a Key Index. The Key Index allows the retrieval of the 
long Key Entry and/or the AD, as necessary. 

15 

According to one embodiment of the present invention, the method for 
searching a submitted key in a list of Coded Keys utilizes Partially Reconstructed Keys 
(PRKs). A PRK is reconstructed for each Key Entry, based on the previous PRK and 
the current Coded Key, and does not require the use of long Key Entries. The partial 
20 reconstruction proceeds as follows: 

1. The more significant bits of the previous PRK are copied up to the Coded Bit 
(the bit at the position defined by the Coded Key). 

2. The Coded Bit is set to "1". 

3. The less significant bits after the Coded Bit are considered to be "unknown" and 
25 are denoted by "U'\ Alternatively, these bits may be represented by zeros and 

disregarded during the search procedure. 

17 



It is noted that the PRK list is generated under the assumption that the first Key Entry in 
a list or the Key Entry preceding the first one in a list has a specified reference value. 
For simplicity, this value is usually "all zeros", in this case, 000000. Thus, the first 
Coded Key is the MSB that is equal to 1. The corresponding PRK has a value of "1" 
for the Coded Bit, "zeros" in all the more significant bits and "unknown" values in all 
the less significant bits (e.g., 0001UUUUU for Coded Key = 5). 

Table 2 shows the PRK corresponding to the current Key Entry in the example 
of Table 1. The Coded Key for the current Key Entry 101110 is 2, as before. The 
Coded Bit is shadowed. The less significant bits after the Coded Bit in the PRK are 
denoted by "U". 



Table 2: Example of a Coded Key and PRK Corresponding to the Change 

in a Long Key Entry 





Kev Entry 
(5432 10) 




Coded Kev 


PRK 

(543210) 


Previous Key Entry 


101000 




5 


1UUUUU 


Current Key Entry 


10 1110 


-> 


2 


1UU1UU 



Table 3 shows another example of applying the Key Coding method (with the 
PRKs) in a list of Key Entries, starting with 100001. Since the MSB that is equal to 1 is 
in this case 5, the Coded Key is 5. In each PRK, the more significant bits of the 
previous PRK are copied up to the Coded Bit, the Coded Bit is set to "1", and the less 
significant bits after the Coded Bit are denoted by "U". 

According to the present invention, the method for searching a submitted key in 
a list of Coded Key preferably uses PRKs, each reconstructed for a Key Entry based on 
the previous PRK and the current Coded Key. Each PRK is sequentially compared with 
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the submitted Key. The key search may yield an Exact Match for binary integers or a 
Range Match for range integers. 

Table 3: Example of Key Coding Method Applied to a List of Key Entries 



Kev Entry 
(5432 10) 




Coded Kev 


PRK 
(543210) 


100001 


— > 


5 


1 uuuuu 


100010 


— » 


1 


1UUU1U 


10010 1 


-» 


2 


1UU1UU 


101000 


-> 


3 


1U1UUU 


101001 


-» 


0 


1U1UU1 


10 1011 


-» 


1 


1U1U1U 



5 

The Exact Match search algorithm consists of two main steps: 

1. Sequential comparison of the Searched Key with the PRKs and tracking of the 
possibly matching results (marked with The possibly matching results are 
the PRKs where all the bits "1" contained in the PRKs are also included in the 

10 Searched Key at the same positions (the other bits of the PRKs, denoted by "U", 

are disregarded). The last matching result, involving the largest Key Entry, is a 
Potential Exact Match Key (PEMK). If no possibly matching results are found, 
a No Exact Match indication may be issued and the search algorithm is over. 
Note: If a "zero" Key is searched, no possibly matching results are found in step 

15 1. However, in this special case, the search algorithm is not over and step 2 is 

performed, and the first Key Entry in the list, which is the PEMK in this case, is 
retrieved. 

2. Checking for actual Exact Match by comparing the Searched Key with the 
PEMK. If this Key Entry is an Exact Match, the AD may be retrieved according 

20 to the respective Key Index; if not, a No Exact Match indication may be issued. 

Table 4 shows an example of an Exact Match search for the key 100101 (listed 
repeatedly for clarity), by sequential comparison of the Searched Key with the PRKs 

19 



and tracking of the possibly matching results (marked with 4t v" ? ). The last matching 
result yields 1UU1UU corresponding to the Key Entry 100101, which exactly matches 
the Searched Key. Thus, the AD may be retrieved according to Key Index 2. 



Table 4: Example of Exact Match Search Using PRKs 



Key 


Key Entry 




Coded 


PRK 


Search 


Searched Key 


Note 


Index 


(543210) 




Key 


(543210) 


Result 


(543210) 


0 


100001 


-» 


5 


1UUUUU 




100101 




1 


100010 


-» 


1 


1UUU1U 




10 0 101 




2 


100101 


-> 


2 


1UU1UU 


V 


100101 


PEMK 


3 


101000 


— > 


3 


1U1UUU 




100101 




4 


10 1001 


— » 


0 


1U1UU1 




10 0101 




5 


101011 


-> 


1 


1U1U1U 




100101 





5 



It is noted that the Exact Match search algorithm is shown above as an example in 
reference to Table 4, however, it is generally applicable to any type of database 
arranged in logical order. Similarly, the exemplary Range Match search algorithms 
shown below in reference to Tables 5 and 6 are also generally applicable. The validity 
10 of the search algorithms for Exact and Range Matches is systematically proven 
hereinbelow. 

The algorithm for a Range Match search consists of three main steps: 

1. Sequential comparison of the Searched Key with the PRKs. This step is 
identical to that in the Exact Match algorithm, i.e., the last matching result is a 

15 Potential Exact Match Key (PEMK). In this case, however, if no possibly 

matching results are found, the PEMK is specified to be the first long Key Entry 
in the list. 

2. The Searched Key is checked for actual Range Match by comparison with the 
PEMK. This check has three possible results or cases, which are detailed 

20 hereinbelow: an Exact Match, Searched Key larger than the Key Entry, and 
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Searched Key smaller than the Key Entry. In the case of an Exact Match, the 
matching long Key Entry is precisely this match, and the AD can be retrieved. 
In case of a Non-Exact Match, the Most Significant Mismatch bit (MSMb), 
which is the MSB where the Searched Key and the long Key Entry do not 
5 match, must be identified. 

3. When the Searched Key is larger or smaller than the Key Entry, a sequential 
comparison of the Coded Keys with the MSMb is required to determine the 
Range Match. A Range Match can always be found and the AD can be 
retrieved; the identified Key Entry is designated Range Match Key (RMK). 

10 

Case 1: Exact Match 

The case of an incidental Exact Match result during a Range Search (in the 
second step) is identical to the Exact Match procedure for binary integers. Hence, the 
example provided in Table 4 for an Exact Match search for the key 100101 also holds 
15 in this case. 

Case 2: Searched Key Larger than the Matched Key Entry 

This algorithm consists of three main steps (refer to the example provided in 

Table 5): 

20 1 . Sequential comparison of the Searched Key with the PRKs. The last matching 
result is a PEMK. 

2. Identification of the MSMb in the Searched Key corresponding to the last 
matching PRK. In this example, the last matching PRK is 1UUUUU, and 
MSMb = 3, because this is the MSB which is 1 in the Searched Key and 0 in the 

25 long Key Entry. 

3. Sequential comparison of the Coded Keys (starting from one after the PEMK in 
ascending order) with the MSMb, identification of the first Coded Key that is 
larger than the MSMb index (4 in this example), denoted as GTMSMb, 
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selection of the previous long Key Entry (100101) as the Range Match Key 
(RMK), and retrieval of the AD corresponding to the matching Key Index. If 
such a Coded Key is not found, the Searched Key is larger than all the Key 
Entries in the list, and the last Key Entry is the RMK. 

5 Table 5: Example of Range Match Search where the Searched Key 

is Larger than the Matched Key Entry 



Key 


Key Entry 




Coded 


PRK 


Search 


Searched Key 


Note 


Index 


(543210) 




Key 


(5432 10) 


Result 


(5432 10) 




0 


100001 


— > 


5 


1 uuuuu 


V 


101000 


PEMK 


1 


100010 


— > 


1 


1UUU1U 




10 1000 




2 


100101 


— » 


2 


1 UU 1UU 




10 1000 


RMK 


3 


1 10000 


— > 


4 


1 1UUUU 




101000 


GTMSMb 


4 


110001 


-> 


0 


1 1 UUU1 




10 1000 




5 


110011 


-> 


1 


1 1 UU 1 u 




101000 





The algorithm for the Range Match search works in this case for the following 
reasons: 

10 • If the Coded Key is smaller than the MSMb, then the corresponding long Key 

Entry is smaller than the Searched Key. This is because smaller Coded Keys 
correspond to PRKs where the bits that change are less significant than the 
MSMb. 

• Similarly, if the Coded Key is larger than the MSMb, then the corresponding 
15 long Key Entry is larger than the Searched Key. Thus, the first larger Coded 

Key after the MSMb (GTMSMb) represents the first long Key Entry that is 
larger than the Searched Key, so the previous Key Entry is the Range Match 
Key (RMK). 

20 It is noted that a long Key Entry with a Coded Key equal to the MSMb cannot be 
included in the database between the PEMK (found in step 1 above) and the Key Entry 
corresponding to the GTMSMb, as is evident from the proof provided hereinbelow. 
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Case 3: Searched Key Smaller than the Matched Key Entry 

This algorithm consists of three main steps (refer to the example provided in 

Table 6): 

1. Sequential comparison of the Searched Key with the PRKs. The last matching 
result is a PEMK. 

2. Identification of the MSMb in the Searched Key corresponding to the last 
matching PRK. In this example, the last matching PRK is 11U1U1, and MSMb 
= 3, because this is the MSB which is 0 in the Searched Key and 1 in the long 
Key Entry. 

3. Sequential comparison of the Coded Keys (starting from the PEMK in 
descending order) with the MSMb, identification of the first Coded Key that is 
larger than the MSMb index (4 in this example), denoted as GTMSMb, 
selection of the previous long Key Entry (100110) as the Range Match Key 
(RMK), and retrieval of the AD corresponding to the matching Key Index. If 
such Coded Key is not found, then the Searched Key is smaller than all the Key 
Entries in the list, the Searched Key is considered to be out of range, and the 
matching Key Index is assigned the value "-1". 



Table 6: Example of Range Match Search where the Searched Key 
is Smaller than the Matched Key Entry 



Key 
Index 


Kev Entry 
(543210) 




Coded 
Kev 


PRK 
(543210) 


Search 
Result 


Searched Kev 
(543210) 


Note 


0 


100101 


— > 


5 


1UUUUU 




110101 




1 


100110 


—> 


1 


1UUU1U 




110 101 


RMK 


2 


111000 


— > 


4 


1 1UUUU 




110 101 


GTMSMb 


3 


111100 


— » 


2 


1 1 U 1UU 




110101 




4 


111101 


— > 


0 


1 1U1U1 




110101 


PEMK 


5 


111110 


— > 


1 


11U11U 




110101 





The algorithm for the Range Match search works in this case because of the 
following reasons: 
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• If the Coded Key is smaller than the MSMb, then the corresponding long Key 
Entry is larger than the Searched Key. This is because smaller Coded Keys 
correspond to PRKs where the bits that change are less significant than the 
MSMb. 

• Similarly, if the Coded Key is larger than the MSMb, then the corresponding 
long Key Entry is still larger than the Searched Key. Thus, the larger Coded 
Key previous to the MSMb (denoted as GTMSMb) represents the smallest long 
Key Entry that is still larger than the Searched Key, so the long Key Entry 
preceding the GTMSMb is the Range Match Key (RMK). 

It is noted that a- as mentioned hereinabove, a long Key Entry with a Coded Key 
equal to the MSMb cannot be included in the database between the PEMK (found in 
step 1 above) and the Key Entry corresponding to the GTMSMb. 

Maintenance of a Database with Coded Keys 

15 Insertion of Key Entries and Coded Keys 

The insertion of a submitted key in a list of Key Entries requires an additional 
insertion of the corresponding Coded Key and the possible update of this and the next 
Coded Key; all the preceding and succeeding Coded Keys remain unchanged. Prior to 
the key insertion, the location of the inserted key in the Key list must be determined; 

20 one alternative is to perform a Range Match search procedure (where the Searched Key 
is larger than the Matched Key Entry) as previously described. 

Table 7 shows an example of a Key Insertion procedure using PRKs. The 
insertion of 110000 involves the update of the corresponding Coded Key (to 4) and of 
the Coded Key of the next Key Entry (from 4 to 1); all the other Coded Keys remain 

25 unchanged. 
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Table 7: Example of Key Insertion Using PRKs 



List Before Insertion 


Inserted 
Key 


List After Insertion 


Kev Entry 
(543210) 


Coded 
Key 


PRK 

(5432 10) 


Key Entry 
(543210) 


Coded 

IV CV 


PRK 


100001 


5 


1UUUUU 




1 A A A A 1 

10 0 0 0 1 


5 


1 T 7 IT TT TT TT 

1 u u u u u 




i 
i 


1T7TTTT1TT 
1 U U U 1 U 




10 0 0 10 

L \J Vt \J 1 U 


1 


1UUU1U 


100101 


2 


1UU1UU 




100101 


2 


1UU1UU 


110010 


4 


1 1 uuuu 


110000 


110000 


4 


1 1UUUU 


110 10 1 


2 


1 1 U 1UU 




110010 


1 


11UU1U 


110 111 


1 


11U11U 




110101 


2 


11U1UU 










110 111 


1 


1 1U11U 



Removal of Kev Entries and Coded Keys 

The removal of a submitted key from a list of Key Entries requires an additional 
5 corresponding Coded Key and the possible update of the next Coded Key; all the 
preceding and succeeding Coded removal of the Keys remain unchanged. Prior to the 
key removal, the location of the key to be removed must be determined. One 
alternative is to perform an Exact Match search procedure as described hereinabove. 

Table 8 shows an example of a Key Removal procedure using PRKs. The 

1 f\ i 1 1 A0 1 A ;*-»v^K;^ c tV*<» iir^H <^t^ nf thp f^r\Ap>(\ "kV\/ r\f the n^vt kTpv Fntrv ( from 2 

to 4); all the other Coded Keys remain unchanged. 

Updating of Kev Entries and Coded Keys 

The updating of the value of a Key Entry in a list (for instance by a Write 
operation) requires the updating of the corresponding Coded Key and of the next Coded 
15 Key; all the preceding and succeeding Coded Keys remain unchanged. 
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Table 8: Example of Key Removal Using PRKs 



List Before Removal 


Removed 


List After Removal 


Key Entry 


Coded 


PRK 


Key 


Key Entry 


Coded 


PRK 


(5432 10) 


Key 


(543210) 




(543210) 


ivey 




10 0 0 0 1 


c 

5 


1 TT IT TT TT TT 

1 u u u u u 




1 OOOOl 

A u V \J \J x 


5 


1 uuuuu 

•1 \-J «J 


100010 


1 


1UUU1U 




100010 


1 


1 UUU1U 


100101 


2 


1UU1UU 




100101 


2 


1UU1UU 


1100 10 


4 


1 1 uuuu 


110010 


110101 


4 


1 1 uuuu 


110101 


2 


1 1 U 1 uu 




110111 


1 


11UU1U 


110 111 


1 


1 1 U 1 1 u 











Table 9 shows an example of a Key Update procedure using PRKs. The 
updating of 110010 to 101000 involves the updating of the corresponding Coded Key 
(from 4 to 3) and of the Coded Key of the next Key Entry (from 3 to 4); all the other 
Coded Keys remain unchanged. 



Table 9: Example of Key Update Using PRKs 



List Before Update 


Updated 
Key 


List After Update 


Key Entry 
(543210) 


Coded 
Key 


PRK 

(5432 10) 


Key Entry 
(543210) 


Coded 
Key 


PRK 
(543210) 


100001 


5 


1UUUUU 




10000 1 


5 


1UUUUU 


100010 


1 


1UUU1U 




100010 


1 


1 U U U 1 u 


100101 


2 


1 UU 1 UU 




100101 


2 


1 U U 1 u u 


110010 


4 


1 1 U U U U 


10 1000 


101000 


3 


1U1UUU 


110101 


2 


1 1 U 1 UU 




110101 


4 


1 1UUUU 


110 111 


1 


1 1U1 1U 




110111 


1 


1 1 UU 1 u 
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Kev Search in B-Tree Structures Using Coded Keys 

Coded Keys can be applied to any type of search tree structures to significantly 
increase the search rate and reduce the search hardware. Among the varied search tree 
5 structures, the B-tree search procedures in a datalist are particularly efficient, because 
they use several nodes in each level, and many entries in each node. The retrieval of 
many entries per node reduces the number of access times to the database and reduces 
the number of tree levels, thereby speeding op the search process (for a specified 
capacity) or, alternatively, increasing the memory capacity for a specified search rate. 
10 In the B-tree search process, the search interval in the list is repeatedly divided 

in any selected number of parts (in particular, two parts for binary tree, which is a 
special case of B-tree) according to the specific database structure, so that the matching 
entry can be found in fewer steps, assuming that all other system parameters are 
identical. Due to its significant advantages, it is preferable to use a B-tree whenever 
15 possible, in particular, balanced tree structures, where the tree has the same number of 
branches at every decision node and the same maximum number of steps is needed to 
access any database entry. The use of Coded Keys significantly enhances the B-tree 
search in hardware and software applications, because most of the search procedure is 
performed in the list of Coded Keys, which have a logarithmic length compared to the 
20 original key Entries. The B-tree can be used to perform searches for Exact or Range 
Match. The first step in a search is performed in the Coded Keys of the relevant node 
in each tree level to find the PEMK for this level; the original long Key Entries must be 
kept because in each stage of the B-tree search procedure the Searched Key is compared 
with the long Key Entry corresponding to the PEMK to check for a Range Match. The 
25 search then proceeds in the list of Coded Keys to find the Range Match; once found, the 



AD is retrieved, pointing to the relevant node in the succeeding level. The search 
procedure ends with the identification of either an Exact Match (when available) or a 
Range Match and the AD retrieval. 

The search procedure may consist of identical steps, where each node has the 
5 same number of branches and each sequential search interval has the same number of 
entries, or may be combined, involving different number of branches and varied 
intervals in different steps. Also, it must be emphasized that while some of the 
processing operations in each search step are performed using Coded Keys, other 
processing operations may involve searching long Key Entries or other searching steps. 
10 To assess the enhanced advantage of using Coded Keys in a B-tree search 

procedure, assume that the datalist consists of M w-bit words, but the processing logic 
allows simultaneous comparisons of up to only m words, or the bandwidth to the 
memory is allows the simultaneous retrieval of only m words. Then, up to m words 
having m-w bits can be accessed, retrieved and searched in each stage. The number of 
15 words or bits may vary in each stage of the B-tree, depending on the size of the 
database and the selected B-tree structure. If the same number of m words is searched 
in each stage, the comparison process takes s steps, where s = log m M; then s-m words 
or B = s-mw bits must be accessed, retrieved and compared in the search procedure. 
Thus, the bandwidth required for the bus connecting the memory device and the 
20 processing logic is proportional to B = s-m-w. When Coded Keys are used, each w-bit 
long word is coded into a short word having c = log 2 w bits. Then, using the same 
processing hardware, instead of retrieving and comparing m words with m-w bits in 
each stage, a larger number of Coded Keys (with log 2 w bits each) may be retrieved and 
searched together with one w-bit long word (PEMK) required for comparison with the 
25 Searched Key to check for an actual Exact or Range Match. The maximum number of 



Coded Keys that can be retrieved in each stage is: 

n = (m-l)-(w / log 2 M) 

Thus, if the same bandwidth is maintained, a much larger number n of entries can be 
processed at each node, resulting in a total datalist size defined by: 

M c = n s » m s = M, 
which is significantly larger than the previous maximum supported datalist size. 

Alternatively, if the (same) number of search stages is maintained while 
searching the same datalist, then only (m-log? w + m) bits are required for the search at 
each node. The requisite number of bits is significantly smaller than the m*w bits 
required by the conventional B-tree, hence, the search time is greatly decreased, and the 
search rate is appreciably increased. 

If the same number of words M is maintained in the datalist, then, since (» m) 
Coded Keys can be retrieved in each stage, a smaller number of stages, defined by 

s c = Iog n M<log m M = s, 
is required to complete the search procedure, increasing the search rate. 

Figure 1 shows a schematic example of a B-tree structure for a search procedure 
in a very small database that contains M = 512 words, each having w = 128 bits. If the 
same number of words m = 8 is retrieved and searched in each stage, then the 
comparison process takes s = log m M = logg 512 = 3 steps. Thus, s in = 3-8 = 24 words 
or B = s-m-w = 24-128 = 3072 bits must be retrieved and compared in the search 
procedure. 

Using the SMCK algorithm, each word is coded into a Coded Key having c = 
log2 128 = 7 bits. Consequently, instead of retrieving m = 8 words with 8-128 = 1024 
bits in each stage, the following maximum number of Coded Keys (plus one 128-bit 
PEMK) can be retrieved: 
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n = (m-1) w / log 2 w = (8-l>128 / 7 = 128 Coded Keys. 
Thus, the same bus bandwidth can be used to search a larger database containing up to 
n-nn = 128-128-128 = 2 Mega Key Entries (instead of 512 key entries). 

Alternatively, a smaller number of Coded Keys, down to the same number of 
5 Coded Keys as the original words (m = 8) summing 8-7 + 128 = 184 bits (instead of 
1024), can be retrieved in each stage. A smaller number of retrieved and processed bits 
per stage saves processing hardware and reduces the bus bandwidth requirements, such 
that cheaper memory devices can be used and/or higher search rates can be achieved, in 
any tradeoff that is suitable with respect to the search engine requirements. 

10 

Key Search and Maintenance in Two-Dimensional Arrays (TDAs) with Coded 
Keys 

The methods presented previously for searching a submitted key in a list of 
Coded Keys using PRKs and for maintaining a list of Coded Keys can use Two- 

15 Dimensional Arrays (TDAs) based on the search and maintenance methods disclosed in 
pending U.S. Patent Applications assigned to HyWire, Ltd.: RAM-Based Binary CAM 
(Serial No. 10/229,054) dealing with binary integers and RAM-Based RCAM (Serial 
No. 10/229,065) used for range integers, both of which are incorporated by reference as 
if fully set forth herein. A sequential search of the submitted key in the TDAs 

20 presented in these patent applications can be completed in two main steps, one for each 
TDA dimension, where the first step involves a Range Match search in a First Column 
Register (FC-Register). 

The use of Coded Keys for searching a TDA requires a previous generation of 
these Coded Keys from the corresponding Key Entries and their storage in an additional 

25 reduced TDA. The original TDA must be kept, because in each search procedure the 
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Searched Key is compared with the matching long Key Entry corresponding to the 
PEMK to check for an actual Exact or actual Range Match. Similarly, to use an FC- 
Register composed of Coded Keys, the Coded Keys must be generated from the Key 
Entries of the original FC-Register, apart from the TDA, and stored in a separate FC- 
5 Register. Alternatively, the first step in the search procedure can be performed using 
the original FC-Register, in which case, there is no need to generate Coded Keys for the 
FC-Register. 

The Key search and maintenance procedures in the TDAs listed below present 
the Coded Keys only (and omit the PRKs). The Exact and Range Match search 
10 algorithms, respectively, are extensions of the algorithms presented hereinabove. 
Similarly, the maintenance procedures are extensions of those previously described 
herein. 

In either search or maintenance procedure, each TDA row is handled as a 
separate one-dimensional array. The Coded Keys are generated separately for each 

15 row; the Coded Key corresponding to the first Key Entry in each row is generated by 
comparison with reference value. For simplicity, a common reference value of "all 
zeros" is used for all the rows. The Coded Keys corresponding to the Key Entries listed 
in the FC-Register are generated apart from the TDA by comparing each long Key 
Entry to the previous Key Entry in the FC-Register. Only the first Coded Key, 

20 corresponding to the first Key Entry in the first TDA row, is identical to the first Coded 
Key in the TDA. 

Table 10 shows an example of a TDA and the corresponding FC-Register, used 
below for Exact and Range Match lookups, and for Insertion of 0101101 (= 45), and 
also for the Removal of 0101100 (= 44). For clarity, each entry in the TDA and the FC- 
25 Register includes the decimal and binary values of the long key entry and then the 
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corresponding Coded Key. The first Coded Key in TDA each row is generated in 
reference to 0000000. The Coded Keys listed in the FC-Register (except the first 
Coded Key) are generated apart from the TDA by comparing each long Key Entry with 
the previous long Key Entry. 



Table 10: Example of Coded Keys in a TDA and the Corresponding FC-Register 



FC- 
Register 



2 

00000 10 

1 



18 
0010010 
4 



34 
0100010 
5 

50 
01 10010 
4 

66 
1000010 
6 



Key 
Index 


o 


1 


2 


3 


4 


5 


6 


7 


0 


2 

0000010 

1 


4 

0000100 
2 


6 

0000110 
1 


8 

0001000 
3 


10 
0001010 

1 


12 

0001 100 
2 


14 
0001 1 10 
1 


16 
0010000 
4 


1 


18 
0010010 
4 


20 
0010100 
2 


22 
00101 10 

1 


24 
001 1000 
3 


26 
001 1010 
1 


28 
001 1 100 
2 


30 
001 1 1 10 
1 


32 
0100000 
5 


2 


34 
0100010 
5 


36 
0100100 
2 


38 
01001 10 
1 


40 
0101000 
3 


42 
0101010 

1 


44 
0101 100 
2 


46 
0101 1 10 
1 


48 
01 10000 
4 


3 


50 
0110010 
5 


52 
01 10100 
2 


54 
01 101 10 
1 


56 
01 1 1000 
3 


58 
01 1 1010 
1 


60 
01 1 1 100 
2 


62 
01 1 1 1 10 
1 


64 
1000000 
6 


4 


66 
1000010 
6 


68 
1000100 
2 


70 
10001 10 
1 


72 
1001000 
3 


74 
1001010 
1 


76 
1001 100 
2 


78 
1001 1 10 
1 


80 
1010000 
4 



Key Search Using Coded Keys in TP As 

The two main steps in a sequential search of the submitted key in a TDA using 
Coded Keys are: 

• Step 1: This step is identical for Exact and Range Match lookups, and involves a 
Range Match search of the Searched Key in the FC-Register. The Range Match 
Key (RMK) resulting from this search points to the TDA row where the key 
entry may be located. In this example, the Range Match search of the Searched 
Key 0101101 (= 45) in the FC-Register yields RMK = 0100010 (= 34), which 
points to the third TDA row (indexed 2). 
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• Step 2: In this step, the Searched Key is looked up in row # 2 identified in Step 
1. This step differs for Exact and Range Match lookups. An Exact Match 
search procedure is performed as previously described, yielding a Potential 
Exact Match Key (PEMK), which may correspond to an exact matching long 
5 Key Entry (if included in the TDA). In this example, 0101101 is not included in 

the TDA and the search yields a No Exact Match result. A Range Match search 
proceeds as previously described, where the Searched Key is larger than the Key 
Entry; and may yield an RMK, which is the matching long Key Entry. In this 
case, the search result is RMK = 0101100 (= 44). 

10 

Maintenance of Key Entries and Coded Keys in TDAs 

The insertion of a submitted key in a TDA row requires an additional insertion 
of the corresponding Coded Key and the possible update of this and the next Coded 
Key; all the preceding and succeeding Coded Keys in the same row remain unchanged. 

15 If the TDA rows are full, then all the Key Entries after the inserted one are shifted 
forward. The last Key Entry and the corresponding Coded Key of this row (and the 
succeeding rows) are shifted to the next row; the shifted Coded Key, being the first in 
the row, is generated by comparison with the reference (usually "all zeros") value and 
generally changes together with the contiguous Coded Key and must be updated. The 

20 last Key Entries shifted forward to the next rows replace the previous first Key Entries 
in the FC-Register. Since the Coded Keys of the FC-Register are generated by 
comparing each long Key Entry to the previous Key Entry in the FC-Register, then the 
Coded Keys corresponding to the shifted Key Entries change and must also be updated. 
Prior to the key insertion, the location of the inserted key in the TDA must be 

25 determined; one alternative is to perform a Range Match search procedure as described 
hereinabove. 

Table 11 demonstrates the effect of inserting the submitted key 0101101 (= 45) 
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in the TDA and the FC-Register shown in Table 10. The last Key Entries of row # 2 
and the succeeding rows of the TDA shown in Table 10 appear as first Key Entries in 
the TDA and in the FC-Register of Table 11. The new Coded Key values (sometimes 
unchanged) are shadowed in the TDA and the FC-Register. 

Table 11: Example of a TDA after Key Insertion 



FC- 
Register 



2 

0000010 

1 



18 
0010010 
4 



34 
0100010 
5 



48 
0110000 
4 



64 
1000000 
6 



80 
1010000 
4 



Key 
Index 


0 


1 


2 


3 


4 


5 


6 


7 


0 


2 

0000010 

1 


4 

0000100 
2 


6 

00001 10 
1 


8 

0001000 
3 


10 
0001010 

1 


12 
0001100 
2 


14 
0001 1 10 
1 


16 
0010000 
4 


1 


18 
0010010 
4 


20 
0010100 
2 


22 
0010110 

1 


24 
0011000 
3 


26 
001 1010 

1 


28 
001 1 100 
2 


30 
001 1 1 10 
1 


32 
0100000 
5 


2 


34 
0100010 
5 


36 
0100100 
2 


38 
0100110 

1 


40 
0101000 
3 


42 
0101010 

1 


44 
0101 100 
2 


45 
0101 101 
0 


46 
0101 1 10 
1 


3 


48 
0110000 
5 


50 
0110010 
1 


52 
0110100 
2 


54 
01 10110 
1 


56 
0111000 
3 


58 
01 1 1010 
1 


60 
0111100 
2 


62 
0111110 
1 


4 


64 
1000000 
6 


66 
1000010 
1 


68 
1000100 
2 


70 
10001 10 
1 


72 
1001000 
3 


74 
1001010 
1 


76 
1001100 
2 


78 
1001 110 
1 


5 


80 
1010000 
6 

















The removal of a submitted key from a TDA row requires an additional removal 
of the corresponding Coded Key and the possible update of the next Coded Key; all the 
preceding and succeeding Coded Keys in the same row remain unchanged. If the TDA 
10 rows are to remain full, then all the Key Entries after the removed one are shifted 
backward. The first Key Entry and the corresponding Coded Key of the next row (and 
the succeeding rows) are shifted back to the last position of the previous row; these 
shifted Coded Keys are generated by comparison with the preceding Coded Keys and 
must be updated. The Coded Keys corresponding to the Key Entries shifted backward 
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to the first position in the rows succeeding the removed Key Entry are generated by 
comparison with the reference (usually "all zeros") value; they generally change and 
must also be updated. These Key Entries shifted backward to the first position replace 
the previous first Key Entries in the FC-Register. Since the Coded Keys of the FC- 
5 Register are generated by comparing each long Key Entry to the previous Key Entry in 
the FC-Register, then the Coded Keys corresponding to the shifted Key Entries change 
and must be updated. Prior to the key removal, the location of the key to be removed 
from the TDA must be determined; one alternative is to perform an Exact Match search 
procedure as described hereinabove. 
10 Table 12 demonstrates the effect of removing the submitted key 0101100 (= 44) 

from the TDA and the FC-Register shown in Table 10. The first Key Entries of the 
rows succeeding row # 2 shown in Table 10 appear as last Key Entries in the preceding 
rows of the TDA. Also, the second Key Entries of row # 2 and the succeeding rows of 
the TDA shown in Table 10 appear as first Key Entries in the TDA and in the FC- 
15 Register of Table 12. The new Coded Key values (sometimes unchanged) are 
shadowed in the TDA and the FC-Register. 

The insertion and removal of entries in the TDAs, as presented above, are 
lengthy operations, because these entries are stored in contiguous ascending order, with 
no empty TDA cells in between. The contiguity of entries in the TDA requires a 
20 forward/backward shift of all the entries positioned after the inserted/removed entry. 
Alternative flexible storage schemes may be applied to allow faster Insert and Remove 
operations, for example using Row Index entries associated with Key Entries in the FC- 
Register that point to the physical TDA rows. These row index pointers may determine 
the row ordering, which is no longer required to be monotonic. A newly inserted entry 
25 may be placed in a new row or in an empty cell of the row containing the keys with the 
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nearest value; an entry that is removed from a row may leave an empty cell. Since the 
Coded Keys are generated by comparing each long Key Entry to the previous Key 
Entry, the Coded Keys involved in the insert and remove operations must be updated 
according to the same principles used in the examples described above and shown in 
5 Tables 11 and 12. 



Table 12: Example of a TDA after Key Removal 



FC- 
Register 

2~~ 
0000010 

1 

18 
0010010 
4 

34 
0100010 
5 

52 
01 10100 
4 
68 
1000100 
6 



Key 
Index 


0 


1 


2 


3 


4 


5 


6 


7 


0 


2 

0000010 

1 


4 

0000100 
2 


6 

00001 10 
1 


8 

0001000 
3 


10 
0001010 

1 


12 . 
0001100 
2 


14 
00011 10 
1 


16 
0010000 
4 


1 


18 
0010010 
4 


20 
0010100 
2 


22 
00101 10 

1 


24 
001 1000 
3 


26 
0011010 
1 


28 
001 1 100 
2 


30 
0011110 
1 


32 
0100000 
5 


2 


34 
0100010 
5 


36 
0100100 
2 


38 
01001 10 
1 


40 
0101000 
3 


42 
0101010 

1 


46 
0101 110 
2 


48 
01 10000 
4 


50 
01 10010 
1 


3 


52 
0110100 
5 


54 
0110110 
1 


56 
0111000 
3 


58 
0111010 
1 


60 
0111100 
2 


62 
01 11 1 10 
1 


64 
1000000 
6 


66 
1000010 
1 


4 


68 
1000100 
6 


70 
1000110 
1 


72 
1001000 
3 


74 
1001010 
1 


76 
1001 100 
2 


78 
10011 10 
1 


80 
1010000 
4 





1 0 Updating of Key Entries and Coded Keys in TDAs 

The updating of the value of a Key Entry in a TDA (e.g., by a Write operation) 
requires the updating of the corresponding Coded Key and of the next Coded Key; all 
the preceding and succeeding Coded Keys remain unchanged. The Key Entries and 
Coded Keys of the FC-Register must be updated only if the first Key Entries in the 
15 TDA rows are changed. 
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Key Search and Maintenance Using Coded Keys in Multi-Hierarch y Architecture 



The concept of Multi-Hierarchy Architecture was disclosed in a pending patent 
application on Multi-RAM Binary CAM or RCAM (U.S. Patent Application Serial No. 
10/206,189, which is incorporated by reference as if fully set forth herein). A Multi- 
5 RAM CAM includes an ordered group of G RAMs, regarded as an "extended RAM" 
and denoted as GRAM. The discussion herein is limited to the case in which the key 
entries are stored in contiguous ascending order along the "extended rows" of the G- 
RAM. 

The first columns of the multiple RAMs composing the G-RAM can be 

10 arranged in sequential columns in an integrated First Column RAM (FC-RAM) having 
N rows and G columns. A generic column g of the FC-RAM contains the first column 
entries of RAM # g in the G-RAM. The first column of the FC-RAM (i.e., FC-Register) 
contains the same entries as the first column of RAM # 0. The advantage of the FC- 
RAM is that it points to a specific row of a specific RAM # g; however, when searching 

15 for an extended G-RAM row, only the FC-Register is needed. 

In Multi-Hierarchy Architecture, the FC-Register of a Single or Multi-RAM 
CAM is partitioned in hierarchical blocks according to a numerical system of base B. A 
general hierachical structure consists of k hierarchical blocks, a B k l Register and (k-1) 
RAMs, B k 2 RAM to B° RAM. 

20 Figure 2 shows an example of partitioning of the FC-Register into three 

hierarchical blocks, B 2 Register, B 1 RAM and B° RAM, similar to the FC-RAM 
partitioning presented in U.S. Patent Application Serial No. 10/206,189. The FC- 
Register first column contains AB 2 key entries, wherein the number A is selected to 
meet the condition AB 2 > N, such that the three storing devices contain all the first 

25 column entries. If AB 2 > N, some of the last entries of the B° RAM remain empty. It 
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should be noted that the entries shown in the B 2 Register, B 1 RAM and B° RAM in 
Figure 2 are the row indices (J) of the FC-Register entries and not their values K 0J . 

The partitioning process is performed in recursive mappings of a one- 
dimensional first column array into RAMs with the same entries. In the first mapping, 
5 the FC-Register first column is mapped into a RAM (denoted as B° RAM) with AB 
rows and B columns, so that all the entries whose row indices are multiples of B are 
arranged in its first column; B° RAM may be stored without its first column to save 
storage space. This first column is mapped into the next-hierarchy block (denoted as B 1 
RAM) with A rows and B columns, such that all the entries whose row indices are 
10 multiples of B 2 are arranged in its first column. These first column entries are stored in 
the next-hierarchy block (highest-hierarchy block in this case), which is a one- 
dimensional register with A cells, denoted herein as B 2 Register. 

Thus, the B 2 Register contains all the first column entries whose row indices are 
multiples of B 2 , i.e., K 0 ,j, where J = mB 2 , 0 < m < A-l. The B 1 RAM has A rows and B 
15 columns, and stores all the entries whose row indices are multiples of B, i.e., K 0 ,j, 
where J = nB, 0 < n < AB-1. The lowest-hierarchy block B° RAM stores all the entries 
of the FC-Register in AB rows and B columns. As in the FC-Register, any of the last 
entries of the B 2 Register, B 1 RAM and B° RAM remain empty. 

In general, when the FC-Register first column is large and is partitioned in k 
20 hierarchical blocks, the serial search procedure consists of k+2 steps. The increasing 
number of hierarchical blocks reduces the chip size but adds latency, because the 
number of steps in a serial search procedure is increased. However, these k+2 steps can 
be performed in a pipelined procedure to achieve a high throughput. 

A key search in the Single or Multi-RAM CAM starts with a search in the 
25 hierarchical blocks, specifically in the highest-hierarchy block, the B k 1 Register, using 



a Row Locator to locate the largest key entry that is smaller than (or equal to) the 
submitted key; this key entry points to a specific row in the next-hierarchy block, the 
B k 2 RAM. Then, the submitted key is searched in the specific row of this RAM using a 
Column Locator to locate the largest key entry that is smaller than (or equal to) the 
5 submitted key; this points to a specific row in the B k " 3 RAM. Similar search procedures 
are then performed in the subsequent hierarchical blocks down to the B° RAM. The 
matching key entry in this last RAM points to a specific FC-Register entry and a TDA 
row (in case of a single RAM). In the case of multiple RAMs, the FC-Register entry 
points to an FC-RAM row (if used) and to an extended G-RAM row; the FC-RAM row 
10 may be looked up to find the specific RAM containing the matching key entry in the 
identified row. 

In the 3-level hierarchy shown by way of example in Figure 2, the key search 
starts in the B 2 Register, to locate the largest key entry that is smaller than (or equal to) 
the submitted key; this key entry points to a specific row in the B 1 RAM. Then, the 

15 submitted key is searched in the specific row of this RAM to locate the largest key 
entry that is smaller than (or equal to) the submitted key; this points to a specific row in 
the B° RAM. A similar search procedure is then performed in the B° RAM. The 
matching key entry in this RAM points to a specific FC-Register entry and a TDA row 
(in case of a single RAM) or an extended G-RAM row (in case of multiple RAMs). 

20 Then, the submitted key is searched in this row to find an exact match (for a Binary 
CAM) or a range match (for an RCAM). 

A key insertion or removal in the TDA starts with a search in the hierarchical 
blocks, following an identical procedure to that used for lookups, described above. 
This search points to a specific FC-Register entry and TDA row. Then, the search 

25 proceeds in this TDA row, to determine whether the key exactly matches a key entry. 
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In the case of an exact match, the submitted key can be removed but not inserted; 
otherwise, the submitted key can be inserted after the largest key entry that is smaller 
than this key. 



5 Storage of Key Entries and Coded Keys in Multi-Hierarchy Architecture 

The SMCK algorithm disclosed herein can be efficiently applied to an ASE 
operating with external memories (disclosed in a pending U.S. Patent Application 
assigned to HyWire, Ltd., entitled "Multi-Dimensional Associative Search Engine 
Having An External Memory", which is incorporated by reference for all purposes as if 

10 fully set forth herein) in Single-RAM or Multi-RAM Multi-Hierarchy Architecture. In 
this configuration, the long Key Entries stored in the external Multi-RAMs are 
transformed into short Key Entries to generate a reduced database. Then, the long Key 
Entries of the FC-Register and the hierarchical blocks thereof can also be transformed 
to generate a reduced FC-Register and reduced hierarchical blocks. The physical 

15 location of original (long Key Entries) and the transformed FC-Register and the 
hierarchical blocks thereof must be determined according to the size of the original 
database and the requirements of the Search Engine Manager (SEM) and the external 
memories. One alternative is to locate the reduced FC-Register and hierarchical blocks 
thereof in the SEM, and the original FC-Register and its hierarchical blocks in the 

20 external RAMs. Other alternatives involve the location of only part of the reduced 
higher hierarchical blocks (and maybe one or more original higher hierarchical blocks) 
in the SEM. 

Figure 3 shows an example of an FC-Register partitioned into three hierarchical 
blocks: B 2 Register, B 1 RAM and B° RAM (depicted in Figure 2). In this example, the 
25 FC-Register has 15 entries and the numerical base for the partition is 3 (B = 3, A = 2). 
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Each entry in the FC-Register includes the decimal and binary values of the long key 
entry and then the corresponding Coded Key, as in Table 10 above. The FC-Register 
corresponds to a single TDA, similar but much larger to the one exemplified in Table 

10. The Coded Keys listed in the FC-Register (except the first) are generated apart 
5 from the TDA by comparing each long Key Entry with the previous long Key Entry. 

The first Coded Keys in the rows of the three hierarchical blocks are generated in 

reference to 00000000. 

Kev Search Using Coded Keys in Multi-Hierarchy Architecture 

10 The key search procedure for a single TDA (not shown) with an FC-Register 

partitioned into three hierarchical blocks starts with a search in the B 2 Register, to 
locate the largest key entry that is smaller than (or equal to) the submitted key; this key 
entry points to a specific row in the B 1 RAM. Then, the submitted key is searched in 
the specific row of this RAM to locate the largest key entry that is smaller than (or 

15 equal to) the submitted key; this points to a specific row in the B° RAM. A similar 
search procedure is then performed in the B° RAM. The matching key entry in this 
RAM points to a specific FC-Register entry and a TDA row. Then, the submitted key 
is searched in this row to find an exact match (for a Binary CAM) or a range match (for 
an RCAM). 

20 All the steps in the search procedure, except the last one, are identical for exact 

and range match lookups and involve Range Match searches (where the searched key is 
larger than the matched key entry). When Coded Keys are used, each of these search 
steps yields a Range Match Key (RMK), as previously described. The final step results 
in a Potential Exact Match Key (PEMK), which may correspond to an exact matching 

25 long Key Entry (if included in the TDA), or to an RMK, in the case of a range match. 
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Another exemplary search procedure is described hereinbelow, with reference to 
Figure 3. The searched key is 00110111 (= 55). The search steps are described below 
assuming that they are performed using Coded Keys. 

The first step is performed in the B 2 Register. It yields RMK = 00000010 (= 2), 
which points to the first row (indexed 0) of the B 1 RAM. The second step, performed 
in the B 1 RAM, results in RMK = 00110010 (= 50), which points to the second row (# 
1) of the B° RAM. The third step yields again RMK = 00110010 (= 50), pointing to 
the fourth entry (# 3) of the FC-Register. The last step is performed in the fourth TDA 
row. Assume that the TDA shown in Table 10 is part of the TDA being searched so that 
this step is performed in the fourth row of this TDA. An Exact Match search yields a 
No Exact Match result because 00110111 is not included in the TDA. A Range Match 
search yields RMK = 00110110 (= 54). 

Maintenance of Kev Entries and Coded Keys in Multi-Hie rarchv Architecture 

Insertion of Key Entries and Coded Keys in Multi-Hierarchy Architecture 

The insertion of a submitted key in a TDA row requires an additional insertion 
of the corresponding Coded Key and the possible update of this and several other 
Coded Keys in the TDA, as described herein and as shown in Table 1 1 . The possibly 
updated Coded Keys are the added Coded Key and the Coded Key following thereafter. 
For the TDA rows to remain full, all the Key Entries after the inserted one are shifted 
forward; consequently, the first Coded Keys together with the contiguous Coded Keys 
in the rows succeeding the inserted Key Entry generally change and must be updated. 
Also, the Coded Keys of the FC-Register corresponding to the shifted Key Entries 
change and must be updated. The updated Coded Keys of the FC-Register generate 
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subsequent an updating of Coded Keys in all the hierarchical blocks of the FC-Register. 
These updates are similar to those performed in the TDA. 

Removal of Key Entries and Coded Keys in Multi-Hierarchy Architecture 

The removal of a submitted key from a TDA row requires an additional removal 
of the corresponding Coded Key and the possible update of several Coded Keys in the 
TDA, as described herein and as shown in Table 12. First, the Coded Key following 
the removed one is possibly updated. For the TDA rows to remain full, all the Key 
Entries after the removed one are shifted backward; consequently, the first and last 
Coded Keys after the removed Key Entry generally change and must be updated. Also, 
the Coded Keys of the FC-Register corresponding to the shifted Key Entries change and 
must be updated. The updated Coded Keys of the FC-Register generate subsequent 
update of Coded Keys in all the hierarchical blocks. These updates are similar to those 
performed in the TDA. 

Updating of Key Entries and Coded Keys in Multi-Hierarchy Architecture 

The updating of the value of a Key Entry in a TDA (e.g., by a Write operation) 
requires the updating of the corresponding Coded Key and of the next Coded Key; all 
of the preceding and succeeding Coded Keys remain unchanged. The Key Entries and 
Coded Keys of the FC-Register must be updated only if the first Key Entries in the 
TDA rows are changed. The updated Coded Keys of the FC-Register generate 
subsequent update of Coded Keys in all the hierarchical blocks. 

Pipelined Search Operation Using Coded Keys 

In the methods presented hereinabove for searching a submitted key in a list of 
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Coded Keys for exact and range integers using PRKs, the first step of the search 
algorithm relates to analyzing the list of Coded Keys and finding a PEMK and the 
second step relates to finding an Exact Match (if available) or an RMK. These methods 
provide a characteristic deterministic search time that is independent of the specific 
content of the key entries, such that a pipelined search can be utilized. Such a pipelined 
search, in which a new search cycle starts during the performance of the previous 
search cycle, enables ongoing parallel search operations and provides a significant 
increase in high throughput with respect to non-pipelined operations. 

Proof of the SMCK Algorithms 

Without limiting the generality of the proofs provided hereinbelow, it is 
assumed that a "zero" Key is not included in the database. 

Coded Key Definition 

Assume a finite list of M integer Keys: K 0 , K,, ... , K M -|. The key list is arranged in 
ascending order: K 0 < K| < . . . < K M -i (there are no two identical numbers in the list). 

Each Key Kj consists of N bits and can be presented in the following binary notation: 

Ki = k s N -i k 5 N-2 ■ • - Vi k* 0 , where 0 < i < M-l. 
A Coded Key CKi is generated for each Key Ki in the following way: 
Generate CK 0 : 

Assume that k°j is the Most Significant Bit (MSB) that is equal to 1. Then CK 0 = j. 
Generate CKi : 

Compare the key Ki bit by bit (from MSB to LSB) with the previous key in the list, Km: 
Kj = kVi kVi-2 ... k 1 ! k'o 
K M =k i, N _ 1 k i -V2... k M |k M 0 
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Suppose that the bits with index j are the first (most significant) ones to be different, 
i.e., 

k i m = k i " l „forN-l >n>j 

5 kj*k M j 

Then CKj = j. 

Theorem 1 (based on the CK { generation procedure): If CKj = j (i > 0), then kj = 1 and 
k M j = 0. This is because Kj > K M . 

A Searched Key (SK) has the same length (number of bits) as the Keys in the key list. 
10 SK = sk N _i sk N _ 2 ... sk] sk 0 

Exact Search 
Problem Definition 

Find the index i of the key Kj in the list that is equal to SK. The key Kj is denoted as 
15 Exact Match Key. If no key in the list is equal to SK, then the search result is "Key Not 
Found". 

Exact Search Algorithm 

The algorithm for Exact Match search consists of two main steps: 
20 Step 1 

la. For each Coded Key CKj, generate an N-bit number PKj = pk' N _i pk' N . 2 ... pk\ pk ! 0 , 
denoted as Partially Reconstructed Key (PRK). The PRK is generated as follows: 

Generate PKp : 

Define that all the bits of PK 0 are equal to 0 except the bit with index equal to CK 0 . 
25 This means: 

For eachj =0 ... N-l, where j * CK 0 : pk°j = 0 

Forj = CK 0 : pk°j = 1 

Generate PKj : 

All the bits of PKj with indices greater than CKj are equal to the corresponding bits of 
30 PKj.,. The bit with index CKj is equal to 1. All the other less significant bits are equal to 
0 and represent unknown values (denoted by "U" in previous tables). This means: 
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For each j > CYL\: pk) 
Forj = CKii pk S j = 1 
For each j < CKj: pk'j 



= P k-' J 

= 0 (unknown value) 



5 lb. Compare each of the M PRKs, PK;, where 0 < i < M-l, with SK, in order to 
generate a "Validity bit", denoted as b\. This bit is generated as follows: 

Generate b i for each PKj i 

Compare skj with pkj for each bit j (0 < j < M-l) 
If pk 1 ) = 1 and skj = 0 for any j, then bi = not_valid. 
10 If no j is found where pkj = 1 and skj = 0, then bi = valid. 

1c. Search the list of bits b 0 , b|, ... , b M _i, starting from b M .i toward b 0 , to find the first 
value bi (corresponding to the largest PKi) that is valid. This means, finding b i? 
where bi = valid, and b m = not_valid for M-l > m > i. The index i is denoted as 
"i_valid" and corresponds to the PEMK (Kj valid = PEMK). 

15 If all these bits are valid, then i_valid = M-l. 

If all the bits are not„valid, then there is no key in the list that is equal to SK (case 3), 
the search result of this step is VExact Match Not Found", and the search algorithm is 
over. 

Step 2 

20 If bj valid is found, then compare the corresponding key Ki_ va iid with SK: 
If SK = Kj valid (case 1), then matching index = i_valid. 
If SK * Ki valid (case 2), then the search result is "Exact Match Not Found". 



Proof of the Exact Search Algorithm 

25 Theorem 2 (based on Theorem 1): Given a PRK PK i5 for each index j, where pkj = 1 , 
there is a corresponding kj = 1 (in the Key Ki). 

Theorem 3 (based on Theorem 2): If bi is not valid and CK { = J, then there must be at 
least one index j, j > J, such that kj = 1 and skj = 0. 

Theorem 4: If SK is equal to a key Ki in the list, then its bj is valid. 

30 Proof : bi is not valid only if there is a bit in SK that is 0, whereas the corresponding bit 
in PKi is 1. But, according to Theorem 2, PKi has l's only at indexes where Kj also has 
Vs. Since SK is equal to K u then, at each index where PKi has 1, SK also has 1; thus, 
PKi has a valid bj. 
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Step 2 in the algorithm, which yields the search result, defines different actions in three 
different cases. We prove the algorithm for each of these cases separately. 



Case 1: SK = Kj valid 

If SK = Ki_vaiid, then K Lva iid is the Searched Key, so matching index = i_valid. 
5 Case 2: SK * Kj_ va iid 

If SK * Kj vaiid then there are two options: SK > Ki_ va iid or SK < Ki_ va iid- 
If SK > Kj valid then: 
Suppose that there is a key in the list, denoted as K^i, which is equal to SK. This 
key must be greater than K Lva iid, i.e., eql > i_valid. According to Theorem 4, if K eq i 
10 is equal to SK, then its b eq i is valid. But, all b s for i > i_valid are not valid. We 

reached a contradiction, meaning that if SK > Kj_ va iid "then there is no key in the list 
which is equal to SK. 

If SK<Ki_vaiid then: 
Suppose there is a key in the list, Keqi, which is equal to SK. This key must be 
15 smaller than Kj vaiid, i.e., eql < i_valid. 

Compare SK with K i va iid bit by bit from MSB to LSB. Assume that MSMb is the 
first bit index where sk M sMb ^ k ,-Na1,d MSMb> i.e., 
For j > MSMb, skj = k Lva,id j, 

For j = MSMb, sk M sMb = 0, k Lvalid MS Mb = 1 because SK < Ki _ va iid- 
20 If SK = Ke q i then: 

For j > MSMb, skj = k eq, j, 
For j = MSMb, sk M SMb = 0, k eql M sMb = 0. 
Therefore: 

For j > MSMb, skj = k eql j and also skj = k Lva!id j . 
25 Since the list is arranged in ascending order, then for j > MSMb, k eq j = k eql+, j = ... = 

valid 

We know that k eq, M sMb = 0 and k LvaKd M SMb = U thus, there is some key Ki_ chg , eql+1 
< i_chg < i_valid, where k^'^sMb = 0 and k- chg M sMb= 1. For this key, CKi_ ch g = 
MSMb, because this is the MSB that changes (all the more significant bits with 
30 indexes higher than MSMb are the same for all keys between Keqi and Ki vaiid). 

t- • wo\/iL i » chs t i_chg+l _ _ i i_valid 

Forj>MSMb, k- ^ = k j= ... = k j, 

For j = MSMb, k Lchgl MS Mb = 0, k Lchg M sMb = k i - chg+l M SMb= = k'- val,d MSMb = 1. 
Therefore: 

CKi_ chg = MSMb, so pk Lchg MSMb = 1 

35 For i_chg < i < i_valid , CKj < MSMb, so pk ! MSMb = 1 • 

We proved that pk Lvalid M SMb = 1- But sk MS Mb = 0. This means that b Lva Hd = 
not_valid. But we started from the assumption that b i va iid = valid. Thus, a 

47 



contradiction has been reached, meaning that if SK < Kj_ V aiid, then there is no key in 
the list that equals SK. 

Case 3: Valid Bit Not Found 

According to Theorem 4, if SK is equal to a key Kj in the list, then its b\ is valid. In this 
5 case, all b s values are not valid. Therefore, there is no key in the list that is equal to SK. 



Range Search 
Problem Definition 

Find the index i of the largest key K\ in the list that is lower than or equal to SK. The 
10 key Ki is denoted as Range Match Key (RMK). 

The search algorithm involves the Searched Key (SK), the Coded Keys list, and only 
one key from the Keys list. If SK is smaller than all the keys (i.e., SK < K 0 ), then the 
matching index is defined as "-1", indicating that SK is out of range. 

Theorem 5 (based on the RMK definition): If the smallest key in the list that is greater 
15 than SK is denoted as K G tsk, then, the RMK is the contiguous smaller key K G tsk-i, and 
the matching index is "GTSK-1". 



Range Search Algorithm 

Perform step 1 of the algorithm for the Exact Match search. Then, perform the second 
20 step as follows: 

Step 2 

The key search may result in one of four cases. The first three cases apply when a valid 
bit bi_ va iid is found and K i V aiid (= PEMK) is read. 

Case 1: SK = Kj va iid 
25 If SK = Ki valid, then the RMK is K i v aiid, i.e., matching index = i_valid. 
If SK * Kj vaiid then: 

Compare SK with K Lva iid bit by bit, from the MSB toward the LSB. Define the Most 
Significant Mismatch bit (MSMb) as the index of the MSB where sk M SMb * 

ki_valid • _ 

MSMb, 

30 sk n = k Lva,id n for N-l > n > MSMb 

» . i Lvalid 

SKMSMb K MSMb 
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Case 2: SK > Ki_ va iid 
If SK > Kj vaiid, then: 

Search the Coded Key list, starting from CK iV aiid+i to CKm-i, for the first value that 
5 is greater than MSMb (CKi > MSMb). 

If this value CKi is found, then the RMK is Km, which is the key before Kr, i.e., 
matching index = i-1. 

If such a value is not found, then the RMK is the last key in the list, i.e., matching 
index = M-l 

10 Case 3: SK<K Lva iid 
If SK < Kj vaiid, then: 

Search the Coded Key list, starting from CK i V aiid toward CK !? for the first value that 
is greater than MSMb (CKi > MSMb). 

If a value CK\ is found, then the RMK is Km, which is the key before K\; i.e., 
15 matching index = i-1. 

If CKj is not found (CKi < MSMb for all i, 1 < i < i_valid), the matching index = 
-1, indicating that SK is out of range. 

Case 4: Valid Bit Not Found 

If a valid bit is not found, then set Kj vaiid = K 0 . 
20 If SK < Kj vaiid, then matching index = -1 (SK is out of range, as in case 3). 
If SK > Kj valid, then search for the RMK as in case 2. 

Proof of the Range Search Algorithm 

Step 4 in the algorithm, which yields the search result, defines different actions for four 
25 different cases. We prove the algorithm for each of these cases separately. 

Case 1: SK = Kj va iid 

If SK = Kj va iid then, according to the problem definition, Ki va iid is the RMK, i.e., the 
largest key that is lower than or equal to SK. Thus, matching index = i_valid. 

Case 2: SK > K; 

valid 

30 According to Theorem 5, if we find the first (smallest) key in the list that is greater than 
SK, i.e., Kgtsk* then we determine the RMK, which is the contiguous smaller key 
Kgtsk -]• Thus, matching index = GTSK-1. 

The algorithm compares SK with Ki valid, and finds MSMb. The algorithm then 
searches for the first Coded Key from CK i V aiid+! to CK M -i where CKj > MSMb. We 
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will prove now that if such a value is found, then this CK\ is CK G tsk, meaning that 
Kgtsk is the first key that is greater than SK. 

Since SK is greater than K Lv aiid> then K G tsk must be a key in the list that is greater than 

Kj_valid- 

5 We search the Coded Key values from CKj va iid+i to CK M _, to find the first value where 
CKi > MSMb; this value is denoted as CK GT MSMb. We claim that CK G TMSMb = CK GT sk- 

Proof : 

1 . For j > MSMb, skj = k Lva,id j, 

For j = MSMb, sk M sMb = 1, k Lva,id M SMb = 0 because SK > K Lva iid 

10 2. We prove here that if CK Lva iid + i < MSMb, CK Lv aiid + 2 < MSMb, , CK* < 
MSMb, then K, is lower than SK. 

If CKj_va]id+i < MSMb then, 

,i valid+1 i i valid , i valid+1 ,i valid ,i_ valid+1 _ livalid _ r\ 

k~ N-l=k" N-i,k" N .2 = K N _2, ...,K MSMb - ^ MSMb - U 

If CKj vaiid+2 < MSMb then, 

ii valid+2 iivalid+1 ,i_valid+2 _ , i_valid+l lr i - valid+2 *,c*,K - k Lvalid+1 x4CNiK 

15 k~ n_]=K N-l ^ N-2 — N-2> K MSMb — K MSMb 

= 0 

and so on. 

Thus, if all the Coded Keys from CKi _ valid+1 to CKi (i_valid+l < i) are lower than 
MSMb, we obtain: 

20 kVi = k'Vi = ... = k Lva,id N -i = sk N .! 

k'iN-2 - k ,_1 N -2 = ... = k- vaIld N-2 = sk N _2 

kVlSMb+1 = k'^MSMb+l = ... = k- Vahd MSMb+l = SkftflSMb+1 
k'MSMb — k ,_, MSMb — ••• = k'^^MSMb = 0, sk]WSMb = 1 

25 Therefore, SK is greater than Kj. 

3. If CKciMSMb > MSMb, then all the more significant bits of KcmvisMb until index 
CK G TMSMb (excluded) are the same as the bits of K GT MSMb-i- At index 
CKcjMSMb, KcTMSMb is 1 and K GT MSMb-i is 0. Denote CK GT MSMb as CKG; then: 

k GTMSM V, = k GTMSMb, N -i = k Lva,i Vi = sk N ., (N-l > CKG) 

30 k GTMSMb N 2 = k GTMSMb-. N 2 = fcLv-lid^ = sk ^ 2 (N -2 > CKG) 

k GTMSMb cKc = ^ ^TMSMb-^^ _ Q = k^CKC 

k^^cKO = skcKG, because CKG > MSMb. 

We proved that the more significant bits of SK and K GT MSMb are equal until bit 
35 index CKG (excluded). At this index, k GTMSMb C KG is 1 and sk CK G is 0. Therefore, 
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KcTMSMb is greater than SK. According to proof step 2, K G TMSMb-i is lower than 
SK; thus, KcjMSMb is equal to K G tsk, i.e., matching index = GTMSMb - 1. 



4. In this step, we prove that the case CKj = MSMb, denoted as CK E QMSMb, cannot 
occur for the Coded Key values ranging from CKi_ va iid+i to CK G TMSMb- 

5 If CK EQ MSMb = MSMb then: 

k EQMSM V, = k LvaK Vi = sk N -i (N-l > MSMb) 

k EQMSMb N 2 = k i-valid N _ 2 = ^ ^ (N _ 2 > MSMb) 

, EQMSMb t i EQMSMb-1 r\ U'- valk * * 1L 

K MSMb = 1, K MSMb - U - K MSMb 

10 According to proof step 1 , sk M sMb = 1 • 

We proved that the more significant bits of SK and K E QMSMb are equal until bit 
index MSMb (included). At bit index MSMb, they are both 1. We know that 
skj = k EQMSMb j for j > MSMb. However, all the values bj for i > i_valid are not 
valid. Therefore, b E oMSMb is not valid. According to Theorem 3, for some bit 
15 index j, j > MSMb, k^ MSMb j = 1 where skj = 0. But, we proved that skj = 

k EQMSMb for j > MSMb Thus, we reached a contradiction, meaning that 
CK E QMSMb cannot be equal to MSMb. 

If, for CKi, i_valid+l < i < M-l, all CKi < MSMb, then, according to proof step 2, all 
keys Ki, i_valid+l < i < M-l, are lower than SK. Therefore, the largest key in the list 
20 which is lower than or equal SK is the last key, so matching index = M-l. 

Case 3: SK < Ki va iid 

Assume that the first key in the Keys list is lower or equal to SK. We search for the 
greatest key that is lower than or equal to SK (RMK). Denote its Coded Key as CK RM k. 

The algorithm compares SK with K Lva iid, and finds MSMb. Then it searches for the first 
25 Coded Key from CK iV aiid to CKi where CKj > MSMb. Denote this value as CK G TMSMb- 

Proof : 

1 . For j > MSMb, skj = k i - valid j, 

For j = MSMb, sk M sMb = 0- k Lvalid MS M b = 1 because SK < Kj valid 

30 2. We will prove here that if CK iV aiid < MSMb, CKi_ va iid-i < MSMb, . . . , CK ; < 
MSMb, Kj.i is greater than SK. 

If CKj vaiid < MSMb then, 

, i valid .Lvalid-I i_i_valid _ . i_valid-l uLvaH _ t i - va,id_l XjlCMfc 

K~ n_i = K N-l , K N-2 — K N-2»--->K MSMb — 14 MSMb 

If CK vaiid-i < MSMb then, 

,i valid- 1 ,i_valid-2 ,i_valid-l _ . i_valid-2 lr^ valid *\,cwu — k'- vdi * 2 Mcx,iR 

35 k~ N-l = k N-l > K N-2 — K N-2, ...,K MSMb — 11 MSMb 

and so on. 
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So, if all the coded keys from CK i V aiid to CKi (Lvalid > i) are lower than 
MSMb, we will get: 

k ,_1 N-i = kVi = ... = k UNahd N-i = skN-i 

k l_1 N-2 = k l N-2 = . . . = k'- X J,,d N-2 = SkN-2 

5 

k' "VlSMb+1 = k ! MSMb+l = = k^^MSMb+l = SkjviSMb+1 
k' ^MSMb = kVlSMb = = k'^^^MSMb = 1» SkMSMb = 0 

Therefore, Kj_i is greater than SK. 

3. If CKcTMSMb > MSMb, then all the more significant bits of K G TMSMb until index 
10 CKcTMSMb (excluded) are the same as the bits of KcTMSMb-i- At bit index 

CKcTMSMb* KcTMSMbis 1 and K G TMSMb-i is 0. Denote CK G TMSMb as CKG, then: 

k GTMSMbl N _i = k GTMSM Vi = k Lvali V, = sk N -i (N-1 > CKG) 

k GTMSMb-l w 2 = k GTMSMb N _ 2 = fci-volid^ = ^ (N . 2 > CKQ) 
, . . . , 

i*- i GTMSMb-1 n i_GTMSMb _ i _ » Lvalid 

1 5 k CKG = 0 , K CKG = 1 = K CKG 

k LvaIid C KG = sk C KG , because CKG > MSMb. 

We have demonstrated that the more significant bits of SK and K G ™sMb-i are 
equal until bit index CKG (excluded). At this index, k G ™ SMb l C KC is 0 and 
skcKG is 1. Therefore, K GT MSMb-i is lower than SK. According to proof step 2, 
20 K G TMSMb is greater than SK; thus, K GT MSMb-i is equal to the RMK, i.e., matching 

index = GTMSMb-1. 

4. If CK EQ MSMb = MSMb (CK EQM SMb + i < MSMb, . . . ., CK, _ valid < MSMb) then: 
k EQMSMb MSMb = 1, and therefore, pk EQMSMb MS M b = 1 

CKeqmsmih-i < MSMb, and therefore, pk EQMSMb+I M sMb = 1 

25 

CKi vaiid < MSMb, and therefore also pk ! - val,d MSMb = 1 
We know that sk Lva,id MS Mb = 0 

We have proven that PK i V aHd has 1 at the same bit index (i_valid) where SK has 
0, so its bi value (bj vaiid) is not valid. However, we started with the assumption 
30 that bj_ valid is valid. Thus, we reached a contradiction, meaning that CK E QMSMb 

cannot be equal to MSMb. 

If, for CKj, 1 < i < i_valid, all CKi < MSMb, then, according to proof step 2, Ko is 
greater than SK. According to the problem definition, matching index = - 1, indicating 
that SK is out of range. 

35 Case 4: Valid Bit Not Found 

If a valid bit is not found, then it means that for all b i9 0 < i < M-l, bj is not valid. 
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If SK < K 0 , then according to the problem definition, matching index = - 1. 

If SK > K 0 , then the algorithm sets invalid = 0, and performs the same procedure as in 
the case of SK > K L vniid (case 2). If i_valid = 0, then the two following statements are 
true: 

1. SK>K 0 , i.e., SK > K L vniid. 

2. All the bj values where i > 0, i.e., i > i_valid, are not valid. 

The proof for the case SK > K Lva iid uses the initial problem definition data, and the 
above statements (1) and (2). In other words, all the facts assumed in case 2 are true 
for this case also when i_valid = 0. Therefore, the algorithm for case 2 is also 
applicable to this case. 

The case of SK = K 0 is impossible, because, according to Theorem 4, if SK = K 0 , then 
b 0 is valid. But, b 0 in this case is not valid. 

As used herein in the specification and in the claims section that follows, the 
term "monotonic order" and the like refer to one or more rows (or one or more 
columns) in an array in which the key entries (e.g., range boundary values) are in 
ascending order or in descending order. This can be achieved in various ways, as 
demonstrated hereinabove. The term "monotonic order" specifically includes rows 
having a cyclic monotonic order, e.g., 9,15,69,81,2,4,7, or 23,105,222,61 1,8,14. 

As used herein in the specification and in the claims section that follows, the 
terms "coded key entry", "coded entry" and the like refer to a key entry resulting from a 
transformation of at least one ("original") key entry, wherein the coded entry is compact 
with respect to the at least one original key entry. 

As used herein in the specification and in the claims section that follows, the 
term "deterministic transformation" refers to a transformation of at least one key entry 
to a coded key entry, in which the size of the coded entry depends on the size of the at 
least one key entry. 

As used herein in the specification and in the claims section that follows, the 
term "pre-determined transformation" refers to a transformation of at least one key 
entry to a coded key entry, in which the function for performing the transformation is 
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independent of the specific content of the particular key entries being transformed. 

As used herein in the specification and in the claims section that follows, the 
term "pre-determined search" refers to a search within a node (in the case of a search 
tree structure) or a list, in which the amount of data required to perform the search is 
pre-determined, i.e., can be calculated in advance. The term is specifically meant to 
exclude the partial key methods taught by Bohannon, et al., in which the amount of data 
required for a particular search is fundamentally not determinable in advance. 

As used herein in the specification and in the claims section that follows, the 
term "deterministic search" refers to at least one of the following: 

(1) a search within a node (in the case of a search tree structure) or a list, in 
which the amount of data retrieved is substantially independent of 
specific key data. This search is termed "deterministic with. respect to 
specific key data"; 

(2) a search within a node (in the case of a search tree structure) or a list, in 
which the required amount of data for searching the node or list consists 
of coded data and auxiliary data (non-zero), and wherein the required 
amount of auxiliary data is substantially independent of the number of 
keys in the node or list. This search is termed "deterministic with 
respect to a required amount of auxiliary data". 

The term "deterministic search" is specifically meant to exclude the partial key 
methods taught by Bohannon, et ah, in which the amount of data required for a 
particular search depends on specific key data and in which the required amount of 
auxiliary data depends on the number of keys in the node, i.e., as the number of keys in 
the node increases, in the worst-case scenario, additional key retrievals are required. 

As used herein in the specification and in the claims section that follows, the 
term "specific key data" and the like refers to at least one of the following: 
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(1) the particular search (or "input") key in the current search; 

(2) the particular original key entries of a list or node being searched; 

(3) the coded key entries in a list or node being searched. 

5 As used herein in the specification and in the claims section that follows, the 

term "varying bit", used with respect to two or more key entries, refers to a bit in which 
there exists a difference between the compared key entries. 

As used herein in the specification and in the claims section that follows, the 
term "data structure" and the like refers to a node or list for data. 
10 Although the invention has been described in conjunction with specific 

embodiments thereof, it is evident that many alternatives, modifications and variations 
will be apparent to those skilled in the art. Accordingly, it is intended to embrace all 
such alternatives, modifications and variations that fall within the spirit and broad scope 
of the appended claims. All publications, patents and patent applications mentioned in 
15 this specification are herein incorporated in their entirety by reference into the 
specification, to the same extent as if each individual publication, patent or patent 
application was specifically and individually indicated to be incorporated herein by 
reference. In addition, citation or identification of any reference in this application shall 
not be construed as an admission that such reference is available as prior art to the 
20 present invention. 
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